[xrblock] proposed change to discard draft for the issue: duplication packet discards

Qin Wu <bill.wu@huawei.com> Thu, 16 August 2012 03:28 UTC

Return-Path: <bill.wu@huawei.com>
X-Original-To: xrblock@ietfa.amsl.com
Delivered-To: xrblock@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7538121F85AE for <xrblock@ietfa.amsl.com>; Wed, 15 Aug 2012 20:28:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.02
X-Spam-Level:
X-Spam-Status: No, score=-4.02 tagged_above=-999 required=5 tests=[AWL=0.225, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_72=0.6, MIME_BASE64_TEXT=1.753, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fDFxrBjYwAxq for <xrblock@ietfa.amsl.com>; Wed, 15 Aug 2012 20:28:41 -0700 (PDT)
Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 6C4B721F85AF for <xrblock@ietf.org>; Wed, 15 Aug 2012 20:28:41 -0700 (PDT)
Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath) with ESMTP id AJL40393; Wed, 15 Aug 2012 19:28:41 -0800 (PST)
Received: from DFWEML407-HUB.china.huawei.com (10.193.5.132) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 15 Aug 2012 20:26:48 -0700
Received: from SZXEML408-HUB.china.huawei.com (10.82.67.95) by dfweml407-hub.china.huawei.com (10.193.5.132) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 15 Aug 2012 20:26:46 -0700
Received: from w53375 (10.138.41.149) by szxeml408-hub.china.huawei.com (10.82.67.95) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 16 Aug 2012 11:26:41 +0800
Message-ID: <53777A58EAB149DDA8395907307F29B0@china.huawei.com>
From: Qin Wu <bill.wu@huawei.com>
To: xrblock@ietf.org
Date: Thu, 16 Aug 2012 11:26:40 +0800
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0140_01CD7BA2.018B09A0"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.5931
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6109
X-Originating-IP: [10.138.41.149]
X-CFilter-Loop: Reflected
Subject: [xrblock] proposed change to discard draft for the issue: duplication packet discards
X-BeenThere: xrblock@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Metric Blocks for use with RTCP's Extended Report Framework working group discussion list <xrblock.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/xrblock>, <mailto:xrblock-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/xrblock>
List-Post: <mailto:xrblock@ietf.org>
List-Help: <mailto:xrblock-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/xrblock>, <mailto:xrblock-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 16 Aug 2012 03:28:42 -0000

Hi,
Discard count metric block draft 
(http://tools.ietf.org/html/draft-ietf-xrblock-rtcp-xr-discard-05)
supports reporting discards due to packet duplication.

It was suggested on the list to provide backgound information for duplication packet discards.
In the Vancouver meeting,we re-discussed duplication packet discards issue. It was pointed out
RTP packet duplication is not standard method and may break RTCP rules when we do RTCP 
statistics reporting. 

Combining these comments and incorporated proposed change from Varun earlier on the list, 
I propose the following change to the defintion part of Discard Type.

OLD TEXT:
"
      An endpoint MAY send only one of the discard types (early, late,
      duplication packets discard) in one RTCP report or choose to
      report early (DT=1) and late (DT=2), duplication packets discard
      (DT=0) in separate block.  It MAY also send the combined early and
      late discard type (DT=2) in one RTCP compound packet, but not any
      other combination of the three Discard Types.  The endpoint MUST
      not report the the total number of discarded packets covering all
      three discard types.  Instead, two separate report blocks should
      be used to carry duplication packets discard and the combined
      early and late discard respectively.
"
NEW TEXT:
"
      An endpoint MAY report only one of the above four discard types

 blocks in an compound RTCP report in a reporting interval. It MAY

 also report a combination of discard types in a compound RTCP report

 but not all combinations are valid. The endpoint MAY report 

duplicate packet discard (DT=0) block with any other discard (DT=1,

2, or 3) block. Additionally, an endpoint MUST NOT report combined

discard (DT=3) block with early discard (DT=1) or late discard (DT=2)

report block. Note that duplicating RTP packets using RTP 

replication may lead to breakage of RTP media streams or RTCP rules.

 In order not to disrupt all the RTCP statistics, it is recommended 

to duplicate RTP packets as described in [draft-ietf-avtext-rtp-duplication-00]

 which will not cause breakage.

"

Also in the meeting, Kevin raised we should add some text to clarify the use cases and suggest to put into the section 1.4 applicability section.
I propose the following change to the section 1.4 as follows:
OLD TEXT:
"
1.4.  Applicability

   This metric is believed to be applicable to a large class of RTP
   applications which use a jitter buffer.

"
NEW TEXT:
"
1.4.  Applicability

 

This metric is believed to be applicable to a large class of RTP

 applications which use a jitter buffer. For example, in one reporting

 interval, when packets were received but dropped from the jitter buffer

due to either buffer underflow or buffer overflow or both, the discard count

 metric can be used to report such packet discards. In some other cases(e.g.,

desktop video conferencing), duplicating RTP packets using RTP replication 

may be used by media receiver for error concealment.

These duplicated packets can be counted as discards when they are not used and 

dropped by application from jitter buffer, in such cases, the discard count 

metric can be used to report such packet discards due to packet duplication.


"
Regards!
-Qin